문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 게임의 한국어 번역 (문단 편집) ===== 폰트 ===== 오늘날의 [[PC]]나 현세대 게임기인 [[PS4]], [[Xbox One]] 등과 같이 성능이 충분한 기기에선 UTF-8로 문자를 인코딩하고 PC에서나 쓸법한 다국어 지원 가능한 트루타입 폰트를 통째로 가져다 써도 전체 성능의 극히 일부에 지나지 않으며 블루레이 디스크를 기본 미디어로 쓰는 만큼 미디어 용량 문제는 사실상 없다. 이에 반해 레트로 게임기는 성능이 충분하지 않았고 뛰어난 제작사들은 한정된 저장장치 용량, 주 기억장치 용량, 중앙처리장치, 그림처리장치, 음원처리장치 등의 성능을 최대한으로 활용람과 동시에 성능을 낭비하지 않기 위해 각종 수단을 다 썼다. 이는 성능이 낮았던 당시 PC도 피해갈 수 없었다. 당연히 각종 데이터의 범용성은 바닥에 달했다. 오늘날의 [[PC]]나 [[스마트폰]] 등에서 [[PNG]] 파일로 된 그림을 열거나 코덱걱정 없이 동영상을 재생하는 것을 생각하면 안 된다. 2000년대 고성능이라 평가받던 PSP의 주기억장치가 고작 32 MB, DS 는 4 MB 정도고 GBA는 전체 384 KB로 요즘 기준에선 매우 작은 용량이다. 저 작은 용량에 게임에 쓰이는 노래, 그림, 프로그램이 쾌적하게 올라갈 리는 없다. GBA 해상도(240x160)를 가득 채우는 그림파일을 아주 단순히 만들어 보면 240x160x16 bit[* GBA는 15 bit의 색수를 지원하나 바이트 단위로 처리되므로 실질적으로 16 bit를 사용] = 75 KB 그냥 화면 채우는데에 75 KB 를 쓰고 여기에 소리까지 읽어오면 더욱 빡빡해진다. 카트리지는 주기억장치보다 느리므로 카트리지에서 데이터를 가져와 미리 주기억장치에 올려두어야 함을 생각하면 384 KB는 그냥 넘긴다. 당연히 이렇게는 못만든다. 결국 글꼴은 화소당 4비트(4 bpp) 이하로 쓰고[* 다만 글꼴은 안티엘런싱 효과를 제외하면 구분만 할수 있음 되므로 원래는 화소당 1비트(1bpp)여도 충분하다.] 글꼴 크기도 게임에서 쓰는 크기인 8x8 ~ 16x16 수준의 작은 글자를 쓰며~~애초에 이 크기 이상이면 글이 화면의 반을 채우게 된다.~~ 가능한한 적은 글자만을 이용해 전체 글자 수가 1000자가 안되는 경우도 흔하다.[* GBA 시절쯤 가면 Shift-JIS를 써서 4000자 정도는 사용한다.] 그나마 한자를 쓰는 일본판이 이 정도고 북미판은 아예 로마자(대, 소)에 숫자가 끝인 경우가 많다. 유럽판은 확장 아스키를 써 조금 더 많지만 그래봐야 256글자가 안되어 1 바이트 안에 해결된다. 현대 한글 전체 조합이 1만 종류를 넘고 많이 쓰이는 글자만 모아 만든 완성형도 2350자로 훨씬 많다. 후술하겠지만 글자 가짓수 차이는 작게는 글꼴의 용량이 달라져 공간을 확장해야 하는 문제, 크게는 아예 256가지가 안 되어 게임내에 2바이트 문자 인코딩 체계를 쓸 수 없어 프로그램을 개조해야 하는 문제를 만든다. 즉 문자 복호화 루틴을 바꿔줘야 한다. 이게 심한 경우 복호화 루틴이 여러 개 존재하며 같은 글꼴을 쓰더라도 서로 다른 복호화 루틴으로 복호화한다. 동작은 거의 같아 동일한 방식으로 고칠 수는 있지만 그걸 찾는 것은 다른 문제이다. 최악은 게임 전체 글꼴을 모두 VRAM에 올려두고 쓰는 경우인데 이런 경우 매번 필요한 글자를 미리 추출해 VRAM에 올려버리는 상당히 어려운 기술을 써야 제대로 된 한글을 출력할 수 있다. 그나마 이 경우는 VRAM에 비해 글자가 적을 때 가능한 것으로 한번에 출력해야 하는 글자수가 VRAM이 버틸 수 있는 양보다 많다면 같은 자리에 글자를 겹쳐서 한글을 만들어 내야 한다... 문자코드를 복호화하는 부분을 넘어서 화면 출력까지 싹 뜯어고치는 대규모의 프로그래밍 작업이라 잘 쓰이지 않는다. 이런 경우 상대적으로 미려하진 못하지만 구현이 간단한 반조합을 쓰는 경우가 많다. 이 겹치는 방법도 게임이 여러 장의 배경을 겹칠 수 있는 경우나 해 볼 법한 방법으로 풀어쓰기도 반조합도 안쓰고 출력하려면 매번 VRAM을 싹 새로 쓰는 등 삽질이 이만 저만이 아니다. 글자 가짓수가 차이나면(당연히 한글이 많다) 원래 글꼴 그림을 읽어오던 루틴을 고쳐서 다른 부분에서 읽어오게 만들어야 하는데 관련 지식이 없으면 이마저도 힘든 작업이 된다. 카트리지가 커지면 가격이 오름, 지역성 문제 등으로 글꼴이 저장된 곳 근처는 각종 데이터로 가득 찬 경우가 많아 그 자리에서 확장이 불가능하기 때문이다. 이 가운데 간단한 경우라면 적당히 지시자만 바꿔도 해결되지만 파일시스템을 쓰는 경우엔 호락호락하지 않은 경우도 있어 프로그램을 고쳐야 할 수 있다. 반각 출력을 전각으로 바꾸는 작업은 화면에 글자를 출력하는 부분을 찾아 읽어올 데이터의 양과 출력 지점의 좌표 등을 다 바꿔줘야하기 때문에 더 높은 수준의 지식을 요구한다. 이미 컴파일 된 만큼 기계어로 짜여 있으니 쉬울리가 없기 때문이다. 덤으로 글자 폭도 반각인 경우가 있는데 이런 경우 한글을 출력하기 매우 나쁘다. 일본어는 일반적으로 전각을, 영어는 반각만 쓰지만 한자 사용이 적은 게임들 가운데 일부는 대사창의 크기를 줄이기 위해 일본어임에도 반각을 쓰는 경우가 있다. 가나는 의외로 자형이 단순하여 8x16에 어렵지 않게 들어가도 한자 가운데서도 넣을 수 있는 경우가 있다. 반면 한글은 8x16에 쉽게 들어가지도 않으며[* 물론 8x16 폰트가 많이 개발되어있다. 당장 포켓몬스터 금은만 해도 8x16이다.] 조합 가짓수가 너무 많아 미려하게 만들기는 더 어렵다. 프로그램의 수정을 피하고자 반각글꼴을 그대로 쓰고자 할 경우 반각한글을 만들어야 하는데 유니코드에는 완성형 반각한글 따위는 없다. 있었다면 많은 글자를 지원하는 [[굴림]] 같은 글꼴에서 이를 지원했겠지만 그렇지 않기에 직접 만들거나 다른 누군가가 작업한 것을 받아와야 하는데 이것도 문제다. 꼼수를 써서 한글을 반으로 쪼갠 뒤 (가의 왼쪽 절반과 오른쪽 절반을 다른 조각에 저장하는 등) 서로 다른 코드를 배정해 합친다면 프로그램 수정 없이 넘길 수 있지만 프로그램 입장에서의 대사량이 2배로 불어난다. 이는 또 다른 용량 문제를 만들어낸다. 프로그램 수정을 감수하고 그렇다고 전각출력을 하려면 그것도 그것 대로 문제인 게 출력되는 대사 길이가 2배가 되니 글자수 압박이 커지고 프로그램도 고쳐야 한다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기